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Portions of the disclosure of this patent document contain material that is subject to 
copyright protection. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document or the patent disclosure as it appears in the Patent and 
Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. 

BACKGROUND OF THE INVENTION 

L FIELD OF THE INVENTION 

The present invention relates to an application programming interface (API) for writing 
a scriptable plug- in, 

2. BACKGROUND ART 

Platform independent programming languages allow a virtual machine to be opened in a 
host application. The virtual machine creates its own environment within the host application 
and runs computer programs in its environment without regard to the type of computer system 
the host application is running. This is useful, for instance, when a person is using the Internet 
and the virtual machine is opened in a host application such as a web browser. 

To extend the functionality of the web browser, plug- ins are used. The use of a plug- in 
allows a developer to write a computer program that performs some desired task from within 
the web browser. For instance, a common plug-in relates to sound. When a web page on the 
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Internet is encovintered that uses soxind, the appropriate plug-in is initiated and it instructs the 
web browser how to handle the sounds and play them for the user. 

An application program interface (API) is often used by a developer to create plug-ins. 
Current plug- in APIs are non-scriptable, meaning that they cannot be implemented in scripting 
languages such as Javascript, Perl or Python. This is disadvantageous because the laige number 
of script developers and existing scripting codes cannot be leveraged in plug- in programming. 
Before further discussing this problem, an overview of platform independent programmir^ 
languages is provided. 

Platform Independent Programming Languag e 

An example of a platform independent programming language is the Java™ technology 
platform. A program which utilizes Java™ technology is composed of a number of classes and 
interfaces. Unlike many programming languages, in which a program is compiled into machine- 
dependent, executable program code, programs which utilize Java™ technology are compiled 
into machine independent bytecode class files. Each class contains code and data in a platform- 
independent format called the class file format. The computer system acting as the execution 
vehicle contains a program called a virtual machine, which is responsible for executing the code 
in classes. The virtual machine provides a level of abstraction between the machine 
independence of the bytecode classes and the machine-dependent instruction set of the 
underlying computer hardware. Figure 1 is a block diagram illustrating a satnple network 
application environment, for instance a Java™ technology network application environment, 
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comprising a client platf onn 102 coupled over a^network 101 to a server 100 for the purpose of 
accessing class files for execution of an application or applet 



Sample Network Application Environment 

In F^;ure 1, server 100 comprises development environment 104 for use in creatii^ the 
class files for a given application. The development environment 104 provides a mechanism, 
such as an editor and an applet viewer, for generating class files and previewing applets. A set of 
core classes 103 comprise a library of classes that can be referenced by source files containing 
other classes. From development environment 104, one or more source files 105 are generated. 
Source files 105 contain the programmer readable class definitions, including data stmctures, 
method implementations and references to other classes. Source files 105 are provided to 
compiler 106, which compiles source files 105 into compiled ".class" files 107 that contain 
bytecodes executable by a virtual machine. Bytecode class files 107 are stored (e.g., in temporary 
or permanent storage) on server 100, and are available for download over network 101. 

Client platform 102 contains a virtual machine (VM) 111 which, through the use of 
available native operating system (0/S) calls 112, is able to execute bytecode class files and 
execute native O/S calls when necessary during execution. Qass files are often identified in 
applet tags within an HTML (hypertext markup language) document. A web server application 
108 is executed on server 100 to respond to HTTP (hypertext transport protocol) requests 
containing URLs (universal resource locators) to HTML documents, also referred to as "web 
pages." When a browser application executing on client platform 102 requests an HTML 
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dociament, such as by forwarding URL 109 to web server 108, the browser automatically initiates 
the download of the class files 107 identified in the applet tag of the HTML document. Qass 
files 107 are typically downloaded from the server and loaded into virtual machine 111 
individually as needed. 

It is typical for the classes of a program to be loaded as late during the program's 
execution as possible; they are loaded on demand from the network (stored on a server), or from 
a local file system, when first referenced durii^ the program's execution. The virtual machine 
locates and loads each class file, parses the class file format, allocates memory for the class's 
various components, and links the class with other already loaded classes. This process makes 
the code in the class readily executable by the virtual machine. 

Plug-In API 

With the understanding of platform independent programming languages and 
networking environment in place, the obstacles of non-scriptable Plug-in API is now discussed. 
There are two main obstacles. First, current plug- in APIs are non-scriptable, meaning that they 
cannot be Implemented in scripting languages such as Javascript, Perl or Python. This is 
disadvantageous because the laige number of script developers and existing scripting codes 
cannot be leveraged in plug-in programming. 

The second obstacle is found the non-scriptable limitation of XPGOM (Cross Platform 
Component Object Model). XPCOM is a technology that allows software components written 
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in various programming languages to communicate with one another within the browser 
environment. However, the powerful potential of having software modules written in different 
languages working together does not extend to modules written in scripting languages. As such, 
software components developed in XPCOM cannot be boxind to software modules 
implemented in scriptable languages. 
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SUMMARY OF THE INVENTTQN 



Embodiments of the present invention relate to a scriptable plug-in API. According to 
embodiments of the invention, all of the interfaces in a conventional, non-scriptable plug- in API 
are mapped to similar interfaces in a scriptable plug- in API. There is no need to change the 
existing plug-in APIs. In one embodiment of the present invention, a set of interfaces and a set 
of wrappers are used to bind the new, scriptable plug-in API to the old one. 

In one embodiment of the present invention, the interfaces comprise at least a header 
and a code file and an IDL (Interface Definition Language) language file used in the cross 
platform standard XPCOM. In another embodiment of the present invention, through the use 
of XPConnect, an interface for connecting scriptable objects to XPGOM objects, the scriptable 
plug-in API is mapped to the non-scriptable plug-in API. In one embodiment of the present 
invention, the following interfaces are made scriptable : Input Stream, Output Strcam, Plugin, 
Plugin Instance, Plugin Instance Peer, Plugin Manager, Plugin Manager 2, Plugin Stream 
Information, Plugin Stream Listener, Plugin Tag Information, Plugin T^ Information 2, 

In one embodiment of the present invention, inter-threading calls for plug-ins are also 
made possible using a proxy that functions with scriptable interfaces. In one embodiment of the 
present invention, the plug-in is written for a Mozilla™ /Netscape™ 6.x browser. In another 
embodiment of the present invention, the scripting languages used to develop the plug-iti 
include Pydion, JavaScript, and Perl. 
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BRIEF DESCRIPTIQN OF THE DRAWINGS 



These and other features, aspects and advantages of the present invention will become 
better understood with regard to the following description, appended claims and accompanyir^ 
5 drawings where: 

Figure 1 is a diagram of a sample network application environment. 

Figure 2 is a scriptable plug- in API according to an embodiment of the present 
invention. 

Figure 3 shows the steps taken to implement a scriptable plug- in API according to an 
embodiment of the present invention. 

Figure 4 A shows the architecture of the API according to an embodiment of the present 
invention. 

Figure 4B shows the architecture of the API according to an embodiment of the present 
invention. 
20 

Figure 5 shows the steps taken to implement the API according to an embodiment of 
the present invention. 
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Figure 6A shows the architecture for in- thread calling. 



Figure 6B shows the architecture for inter- thread calling according to an embodiment of 
the present invention. 



Figure 7 shows a computer embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 



Embodiments of the present invention relate to a scriptable plug- in API. In the 
following description, numeroiis specific details are set forth to provide a more thorough 
description of embodiments of the invention. It will be apparent, however, to one skilled in the 
art, that the invention may be practiced without these specific details. In other instances, well 
known features have not been described in detail so as not to obscure the invention. 

Scriptable Plug-in API Architecture 

According to one or more embodiments of the invention, all of the interfaces in a 
conventional, non-scriptable plug-in API are mapped to similar interfaces in a scriptable plug-in 
API via a bridge. Bridges are software modules that allow two incompatible interfaces to 
operate with each another. More specifically, bridges map the ftinctionality of one interface to 
another interface. As such, with these bridges in place there is no need to change the existing 
non-scriptable plug- in API. F^;ure 2 shows a diagram of a scriptable plug-in API architecturc. 
Non-scriptable plug-in API 200 has interfaces 210, 220 and 230. Scriptable plug-in API 240 has 
interfaces 250, 260, and 270. Bridges 280, 281, and 282 are used to map interface 210 to 250, 
220 to 260 and 230 to 270 respectively. In one or more embodiments of the present invention, 
there is a one to one mappii^ of interfaces in the non-scriptable and scriptable versions of the 
API 200 and 240. Hence, the existing non-scriptable plug-in API 200 needs no modification to 
allow for new scriptable plug- ins. The new scriptable plug-ins can implement scriptable plug-in 
API 240, which operates on top of non-scriptable plug- in API 200 and interfaces with it through 
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the bridges 280, 281, and 282. Thus, the newscriptable plug-ins have access to all functionality 
of the existing non-scriptable plug-in API 

An implementation of scriptable plug- in according to an embodiment of the present 
invention is shown in the flowchart of Figure 3. At block 300, an interface from the non- 
scriptable plug-in API is obtained. At block 310, a corresponding interface from the scriptable 
API is obtained. At block 320, the scriptable interface is implemented in the plug- in. The 
implementation of the interface involves making functions in the plug- in conform to the 
requirements of the scriptable interface. At block 330, the scriptable and non-scriptable 
interfaces are connected with a bridge. In one embodiment or more embodiments of the 
present invention, bridges are a set of interfaces and a set of C++ wrappers used to bind the 
new, scriptable API to the old, non-scriptable one. At block 340, it is determined if there are 
anymore interfaces for the plug- in to implement If not, the process ends. Otherwise, block 
300 repeats. In one or more embodiments of the present invention, the plug-in is written for a 
Mozilla™ / Netscape™ 6.x browser. 

XPQ>nnect Scriptable Components 

In one embodiment of the present invention, an interface is used to connect a scriptable 
lai^age API to a cross platform language API. An example of such an interface is XPConnect. 
It is a technology which enables interoperation between XPCOM and JavaScript. Javascript is 
an example of a scriptable language API while XPOOM is an example of a cross platform 
language that allows software components written in various programming languages to 



LA 55722v3 



10 



communicate with one another within the browser environment. In one or more embodiments 
of the present invention, XPConnect allows JavaScript objects to transparently access and 
manipulate XPCOM objects. XPConnect does this by enabling JavaScript objects to present 
XPCOM compliant interfaces. Thus with XPConnect, Javascript objects can behave as 
XPCOM objects and reap the benefit of interoperability that XPCOM provides. XPConnect 
has been discussed with respect to the JavaScript language but it has equal applicability to other 
common scripting languages, such as Python and Perl. 

Figure 4A shows the architecture of XPConnect according to an embodiment of the 
present invention. XPCOM API 400 and scripting language API 420 are connected via 
XPConnect interface 410. Each XPCOM object has an associated typelib file that is generated 
in the process of creating the XPCOM object. XPConnect interface 410 uses typelib files 411 
and 412 to connect scripting language objects 421 and 422 with XPCOM objects 401 and 402. 
The typelib files allow the XPConnect glue code to dynamically build proxy objects at runtime to 
dispatch method calls and handle property accesses between XPCOM and JavaScript objects. In 
one embodiment of the present invention, the architecturc also defines the nsIXPCScriptable 
interface, an interface that allows XPCOM objects with scripting specific requirements to have 
more control over how they are represented as JavaScript objects. 

Having access to XPCOM objects means that scripting language objects can now access 
objects implemented in non-scriptable plug- in API F^re 4B shows the architecture according 
to an embodiment of the present invention that enables such access. Non-Scriptable plug- in 
objects 441 and 442 of non-scriptable plug-in API 440 are made into XPCOM objects 401 and 
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402, respectively. The process involves generating XPCOM objects out of non-scriptable plug- 
in objects 441 and 442 using an XPIDL compiler. XPIDL is a IDL (Interface Definition 
Language) based language with some extensions to support added XPCOM and XPConnect 
reqviirements. For example, the non-scriptable plug-in API maybe in C++. Then the XPIDL 
compiler is used to generate both C++ header files and typelib files to be used later by 
XPConnect. The C+ + header files are functionally identical to the header files of the C+ + non- 
scriptable plug- in objects. After the XPIDL compilation process, the XPCOM objects 
representing the C+ + objects are generated. The new XPCOM objects allow interoperability 
other XPCOM objects, which may represent objects implemented in other programming 
languages. In Figure 4B, XPCOM objects 401 and 402 behave as stand-in objects, hiding the 
underlying implementation of the non-scriptable plug-in objects 441 and 442. 

In tum, the new XPCOM objects 401 and 402 are accessed by scripting language objects 
421 and 422 via XPConnect interface 410. Thxjs XPConnect works in conjunction with the 
XPCOM API to enable scripting language objects to 2iccess objects created under non-scriptable 
plug-in API 440. This in tum enables the programmii^ of plxig-ins in scriptable languages. 

Figure 5 shows the steps taken by an implementation of XPCoimect according to an 
embodiment of the present invention. At block 500, objects within non-scriptable plug- in API 
are obtained. At block 510, the XPIDL compiler generates XPCOM interfaces for the non- 
scriptable plug- in objects, C+ + header files and XPConnect typelib files. The C+ + header files 
are functionally identical to the header files of the C+ + non-scriptable plug-in objects. The 
typelib files are to be used by XPConnect later. At block 520, a plug-in is written in a scriptable 
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language and it is run. At block 530, it is determined if a property access or a method call 
between XPCOM objects (which represent the C++ objects from non-scriptable plug- in API) 
and the scripting language plug-in is occurring. If so, the typelib files allow the XPConnect glue 
code to dynamically build proxy objects at block 540. Otherwise, the process terminates. Thus, 
5 via XPConnect and XPCOM, the plug-in that is in scripting language can access all the 
functionality defined in the non-scriptable plug-in API. 

Inter-thread Calls 

hah 

Q 

G 1 0 The ability to create plug- ins using scriptable languages enables plug-ins to take 

W advantage of existing inte]> thread calling noechanisms that work only with scriptable interfaces. 

r 3 

One such mechanism is nsISupports proxy. An nsISupports proxy is a stub object which 
r , enables a method of any class to be called on any in-process thread. The only requirement is 

j.^^ that the class needs to be derived from a base class called nsISupports and have a typelib file. 

rs B 

15 

Figure 6A and 6B shows how a scriptable plt^-in can make an inter- threading call 
according to an embodiment of the present invention. In the Mozilla™ browser environnnient, 
Javascript and User Interface are defaulted to be on a sii^le thread. When one is busy, the other 
is blocked. This is shown in Figure 6A Unlike the majority of Javascripts which are small and 
20 can be quicHy run, installation plug- in 600 is a Javascript- based module that performs 

installation tasks that require long execution time due to unzipping or native file system actions. 
If installation plug-in 600 ran on the same thread as the User Interface 610, as in the default 
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setting, then User Interface 610 would be blocked and appear frozen vintil the installation plug-in 
600 script was completed. 

To work aiTound this, installation plug-in 600 was moved to its own thread as shown in 
Figure 6B. Now installation plug- in 600 performs its installations while the User Interface 610 
continues to render on screen and the two do not interfere with one another. However, because 
the two modiiles are on different threads, installation plug- in 600 cannot access User Interface 
elements such as a progress meter or a confirmation dialog. This is where nsISupports proxy 
comes in. The nsISupports proxy creates a proxy object 620 that represents the User Interface 
610 on the same thread as installation plug- in 600. Installation plug- in 600 can now treat proxy 
object 620 as a real object on its thread and call methods of User Interface 610 in proxy object 
620. Thus inter- thread calling is achieved. 

Interfaces 

According to one or more embodiments of the present invention there is no need to 
change the existing non-scriptable plug-in API. Instead, a set of scriptable interfaces are defined 
along with a set of wrappers to bind the API of the present invention to the old non-scriptable 
API. In one embodiment of the present invention, the following interfaces from the non- 
scriptable API are made to be scriptable: 

nsIInputStream, nsIOutputStream, nsIPlugin, nsIPluginlnstance, nsIPluginlnstancePeer, 
nsIPluginManager, nsIPluginManager2, nsIPluginStreamlnfo, nsIPluginStreamlistener, 
nsIPluginTaglnfo, and nsIPluginTagInfo2 
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The corresponding IDL (Interface Definition Language) files are: 



nsIXPIDLInputStream.idl, nsIXPIDLOutputStreanLidl, nsIXPIDLPlugin.idl, 
nsIXPIDLPluginlnstanceidl, nsIXPIDLPluginlnstancePeeridl, 
nsIXPIDLPluginManageridl, nsIXPIDLPluginManagerZidl, 
nsIXPIDLPluginStreamlnfo.idl, nsIXPIDLPluginStreamListener.idl, 
nsIXPIDLPluginTaglnfoidl, and nsIXPIDLPluginTagInfo2.idl. 



The IDL files arc generated by XPIDL and are used by XPGOM to provide XPOOM 
interfaces to the C based interfaces. Scriptablity is achieved when the IDLs are used in 
conjunction with XPConnect. The non-scriptable plug- in API interfaces arc listed below. In 
each interface, the IDL file is listed first. Then the C implementation of the interface is listed. 
Finally listed is the C header file. Both the C implementation and C header file are needed for 
the usage of XPGOM and XPConnect. 



Interface: Input Stream 

Description: an interface designed to handle the input steam of data for the 
plug- in 

The scriptable IDL for this interface is nsIXPIDLInputStreamidl and is as follows: 

# include "nsISupports.idl" 

# pragma prcfix 

[scriptable, uuid (b3199ec2-37c6-4c41-9el8-2a655bc4400e)] 
interface nsIXPIDUnputStrcam : nsISupports 

void closeQ; 

unsigned long available Q; 

unsigned long read( in unsigned long count, 

[array, size_is(count)] in octet buf ); 

}; 
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The C code file for the interface is: 

# include "nsXPIDLInputStreani.h" 

# include "nsIInputStream.h" 

NS_IMPLJSUPPORTSl(nsXPIDLInputStream,nsIXPIDLInputStream) 
nsXPIDLInputStream: insXPIDLInputStreamQ 

NSJNITJSUPPORTSO; 
nsXPIDLInputStream: :nsXPIDLInputStream( nsIInputStream ^inputStream) 

NSJNITJSUPPORTSO; 

this- >inputStream = inputStream; 

NS_ADDREF( inputStrcam); 

nsXPIDLInputStream:: --nsXPIDLInputStreamO 

NS_RELEASE( inputStream); 

NSJMETHODIMP 
nsXPIDLInputStream::Qose() 

return inputStream- XUoseQ; 

NSJMETHODIMP 

nsXPIDLInputStream::Available(PRUint32 ^'-_retval) 

retum inputStream- >Available( _retval ); 
NS^IMETHODIMP 

nsXPIDLInputStream: :Read( PRL^nt32 count, 
PRUintS ^''buf , 
PRUint32 '='_retval) 

retum inputStream- >Read( (char ''')buf, count, _retval); 



The C header file for the interface is as follows: 

# ifndef _nsXPIDLInputStream_included_ 

# define _nsXPIDLInputStream_included_ 

# include "nsIXPIDLInputStream.h" 

# include "nsIInputStream.h" 

class nsXPIDLInputStream : public nsIXPIDUnputStream 

{ 
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public: 

NS_DECLJSUPPORTS 
NS_DECL NSIXPIDUNPUTSTREAM 
nsXPIDLInputStreamQ ; 

nsXPIDLInputStream( nsIInputStream ''inputStream); 
virtual --nsXPIDLInputStreamQ; 
nsIInputStream "''itiputStream; 

}; 

# endif / / _nsXPIDLInputStream__mclucled_ 



Interface: Output Stream 

Description: an interface designed to handle the output stream of data for the 
plug- in 



The scriptable IDL for this interface is nsIXPIDLOutputStream.idl and is as follows: 

# include "nsISupports.idl" 

# pragma prefix 

[scriptable, uuid(5bel7648-6b93-4al7-9d2e-e2fdcff738ee)] 
interface nsEXPIDLOutputStream : nsISupports 

{ 

void closeQ; 
void flxishO; 

unsigned long write( in unsigned loi^ count, 
[array, si2e_is(coimt)] in octet buf ); 

}; 

Hie C code file for the interface is: 

# include "mXPIDLOutputStrcam.h" 

NS_IMPL_ISUPPORTS l(nsXPIDLaitputStrcam, nsIXPIDLOutputStream) 

nsXPIDLOutputStream::nsXPIDLOutpu6treamO 
{ 

NSJMTJSUPPORTSO; 

} 

nsXPIDLOutputStream::nsXPIDLOutputStream( nsIOutputStream *outputStream) 

NSJMTJSUPPORTSO; 

this- >outputStream = outputStream; 

NS_ADDREF( outputStream); 

} 

nsXPEDLOutputStream:: -nsXPIDLOutputStreamQ 
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{ 

NS_RELEASE{ outpu6tream); 

} 

NS_IMETHODIMP 
nsXPIDLOutputStream::QoseO 

{ 

return outputStream- >QoseO; 

} 

NS_IMETHODIMP 

iisXPIDLOutputStream::FlushO 

{ 

return outputStream- ^i'lushQ; 

} 

NS_IMETHODIMP 

nsXPIDLOutputStream::"Wnte( PRL)Int32 count, 
PRUmt8 '=-buf, 
PRUint32 '^_retval) 

{ 

return outputStream- >Write( (char '^)buf, count, _retval); 

} 



The C header file for the interface is as follows: 



# ifndef _nsXPIDLOutputStream_included_ 

# define _nsXPIDLOutputStream_mcluded_ 

# include "nsIXPIDLOutputStream.h" 

# include "nsIOutputStream.h" 

class nsXPIDLCXitputStream : public nsIXPIDLOutputStream 

{ 

public: 

NS_DECLJSUPPORTS 
NSDECLNSIXPIDLOUTPUTSTREAM 
nsXPIDLOutputStreamQ ; 

nsXPIDLOutputStream( nsIOutputStream "outputStream); 
virtual -HisXPIDLOutputStreamQ; 
nsIOutputStream "^outputStream; 

}; 

# endif / / _nsXPIDLOutpu6tream_included_ 
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Interface: Plug - In 

Description: an interface designed to define die default interface for plug-in 
implementation 

5 

The scriptable IDL for this interface is nsIXPIDLPluginidl and is as follows: 

# include "nsIFactoryidl" 
10 # pragma prefix 

[scriptable, uuid(41019dc6-8d53-41fl>b70a-feaa72cfd48b)] 
interface nsIXPIDLPlugin: nsIFactory 

void createPluginInstance(in nsISupports aOuter, 
15 in nsIIDRef iid, 

in string pluginMIMEType, 
[retval, iid_is(iid)] out nsQIResult result); 
j;i void initializeO; 

bi void shutdownO; 

S 20 }; 

5i The C code file for the interface is: 

Vfr, 

^ 25 # include "nsIPlugin.h" 

U # incliide "nsXPIDLPlugin.h" 

i=y NS_IMPL_ISUPPORTSl(nsXPIDLPlugin, nsIPlugin) 

U nsXPIDLPlugin::nsXPIDLPlugmO 

ru { 

O 30 NS_IMT_ISUPPORTS0; 

nsXPIDLPlugm::nsXPIDLPlugin( nsIXPIDLPlugin ''plugin) 
{ 

35 NS_IMT_ISUPPORTS0; 

this- >plugin = plugin; 
NS_ADDREF(plugin); 

} 

nsXPIDLPlv^in:: -nsXPIDLPluginO 
40 { 

NS_RELEASE( plugin); 

} 

NS_IMETHODIMP 

nsXPIDLPlugin::QeatePluginInstance( nsISupports *aOuter, 
45 REFNSIID allD, 

const char* aPluginMIMEType, 
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void aResult ) 

{ 

return plugin- >CreatePluginInstance( aOuter, allD, aPluguiMEMEType, 

aResult); 

} 

NS_IMETHODIMP 
nsXPE)LPliigin::ImtializeO 

return plugin- l^initializeO; 

} 

NS_IMETHODIMP 

nsXPIDLPli^m::ShutdownO 

{ 

return plugin- >6hutdownO; 

} 



The C header file for the interface is as follows: 



# ifndef _nsXPIDLPlugin_included_ 

# define _nsXPEDUPlv^in_included_ 

# include "nsIPlugin.h" 

# include "nsIXPIDLPlugin.h" 

class nsXPIDLPlugin : public nsIPlugin 
{ 

public: 

NSDECLISUPPORTS 

// NS_DECL_NSIXPIDLPLUGIN 

nsXPIDLPluginO; 

nsXPIDLPlugin( nsIXPIDLPlugin *plugin); 
virtual -nsXPIDLPluginO; 
nsIXPIDLPlugin '^plugin; 
// from nsIPli^in 

NS_IMETHODIMP QeatePluginInstance( nsISupports *aOuter, 

REFNSIID allD, 

const char*^ aPluginMMEType, 

void**aResult); 
NS_IMETHODIMP InitializeQ; 
NS_IME'IHODIMP ShutdownQ; 

}; 

# endif // _nsIXPIDLPlugin_included_ 
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Interface: Plug-In Instance 

Description: an interface designed to.define the instance of a plug-in 
implementation 



The scriptable IDL for this interface is nsIXPIDLPluginlnstance and is as follows: 

# include "nsISupports.idl" 

# include "nsIXPIDLPluginlnstancePeeridl" 

# include "nsIXPIDLPluginStreamListenenidl" 

# pragma prefix 

[scriptable, uuid(31e78e3a-dcdl-425e-a938-e04260771738)] 
interface nsIXPIDLPluginlnstance : nsISupports 

{ 

void destroyO; 

void initialize ( in nsIXPIDLPluguiInstancePeer peer); 

nsIXPIDLPluginStreamListener newStreamQ; 

// voidprint( ... ); 

/ / void setWindow( ... ); 

void startO; 

void stopO; 

}; 



The C code file for the interface is: 



# include "nsIPluginInstance.h" 

# include "nsXPIDLPluginInstance.h" 

NS_IMPL_ISUPPORTSl(nsXPIDLPluginInstance,nsIPluginInstanc^ 
nsXPIDLPliiginInstance::nsXPIDLPluginInstanceO 

{ 

NS_INIT_ISUPPORTS0; 
} " . 

nsXPIDLPluginInstance::nsXPIDLPluginInstance(mIXPIDIPli^inIn^ 
''pluginlnstance ) 

{ 

NS_INlT_ISUPPORTS 0; 

this- >plugmlnstance = pluginlnstance; 

NS_ADDREF( pluginlnstance ); 

} 

nsXPIDLPluginlnstance:: ^-nsXPIDLPluginlnstanceQ 

{ 

NS_KELEASE( pluginlnstance ); 

} 
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10 peer); 



Q 



35 



NSJMETHODIMP 
iisXPIDLPluginInstance::DestroyO 

{ 

return pluginlnstance- >DestroyO; 

} 

NS_IME'IHODIMP 

nsXPIDlPlugmInstance::Initialize( nsIPli^inlnstancePeer *peer) 

nsIXPIDLPluginlnstancePeer ''"instPeer = new nsXPIDLPlugirL[nstancePeer( 



return pluginlnstance- :::imtialize( instPeer ); 

} 

NSJMETHODIMP 

nsXPIDLPluginInstance::NewStream( nsIPluginStreamListener **_retval ) 

nsIXPIDLPluginStreamListener "^""sListener, 
nsresult res = pluginlnstance- >NewStream( sListener ); 
'^_retval = new nsXPIDLPluginStreamListener( "'sListener ); 
f :i return res; 

0 20 } 

rU NS_IMETHQDIMP 

m nsXPIDLPluginInstance::StartO 

1 { 

return pluginlnstance- >StartO; 

W 25 } 

NSJMETHODIMP 
nsXPIDLPluginInstance::StopO 

{ 

return pluginlnstance- >Stop(); 

30 } 



The C header file for the interface is as follows: 



# ifndef _nsXPIDLPluginInstance_included_ 

# define __nsXPIDLPluginInstance_included_ 

# include "nsIPluginInstance.h" 

# include "nsIXPIDLPluginInstance.h" 
40 # include "nsIPluginlnstancePeer.h" 

# include "nsXPIDLPluginlnstancePeerh" 

# include "nsIPluginStreamListenerh" 

# include "nsXPIDLPluginStrcamListener.h" 

class nsXPIDLPluginlnstance : public nsIPluginlnstance 
45 { 

public: 
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NS_DECL_ISUPPORTS 

// NS_DEa_NSIXPIDLPLUGIMNSTANCE 

nsXPIDLPluginlnstanceQ; 

nsXPIDLPluginInstance( nsIXPIDLPluginlnstance *plvigmlnstance ); 
virtual ~iisXPIDLPluginInstanceO; 
nsIXPIDLPluginlnstance ^pluginlnstance; 

// from nsIPluginlnstance 
NS_IMETHODIMP DestroyQ; 

NS_IMETHODIMP Initialize ( nsIPluginlnstancePeer "'peer); 
NSIMETHODIMP NewStream( nsIPluginStreamlistener **_retval ); 
NSJMETHODIMP StartQ; 
lSIS_IMETHODIMP StopQ; 

# endif / / _nsXPIDLPliiginInstance_included_ 



Interface: Plug- In Instance Peer 

Description: to define the function requirements for plug-ins to ensure 
compatibility with browser 



The scriptable IDL for diis interface is nsIXPIDLPluginlnstancePeer and is as follows: 

# include "nsISupportsidl" 

# include "nsIXPIDLPluginTagInfo2.idl" 

# include "nsIXPIDLOutputStrcam.idl" 

# pragma prefix 

[scriptable, uuid(20cb8d75-b224-46a5-a30f-73a65445e9b3)] 
interface nsIXPIDLPluginlnstancePeer : nsISupports 

{ 

readonly attribute string MIME Type; 

readonly attribute unsigned long mode; 

readonly attribute nsIXPIDLPluginTagInfo2 taglnfo; 

string getVaIue( in long variable ); 

nsIXPIDLOutputStream newStream( in string type, in string target); 
void setWindowSize( in unsigned long width, in unsigned long height ); 
void showStatus( in string message ); 

}; 



The C code file for the interface is: 

# include "nsIPluginlnstancePeer.h" 

# include "nsXPIDLPluginlnstancePeenh" 

# include "nsIOutputStream.h" 
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# include "nsXPIDLOutputStream.h" 

# include "nsIPluginTagInfo2.h" 

# include "nsXPIDLPluginTagInfo2.h" 

NSJMPLJSUPPORTSl(nsXPIDLPluginInstancePeer,nsIXPIDmugi^^ 
nsXPIDLPluginInstancePeer::nsXPIDLPluginInstancePeerQ 

{ 

NS_E^T_ISUPPORTS0; 
} " . ~ 

nsXPIDLPluginlnstancePeer: :nsXPIDLPluginInstancePeer( nsIPluginlnstancePeer 
^pluginlnstancePeer ) 

{ 

NSJNITJSUPPORTSO; 

this- >pli^inInstancePeer = pluginlnstancePeer, 

NS_ADDREF( pluginlnstancePeer); 

} 

nsXPIDLPluginlnstancePeer:: --nsXPIDLPluginlnstancePeerO 

{ 

NS__RELE ASE ( pluginlnstancePeer ); 

} 

NSJMETHODIMP 

nsXPIDLPluginInstancePeer::GetMIMEType( char '^'aMIMEType ) 
{ 

nsMIMEType "'mimeType = (nsMIMEType "*)aMIMEType; 
return pluginlnstancePeer- >GetMIMEType( minieType ); 

} 

NS_IMETHODIMP 

nsXPIDLPluginInstancePeer::GetMode( PRUmt32 ^aMode ) 
{ 

nsPluginMode "mode = (nsPluginMode "')aMode; 
return pluginlnstancePeer- >GetMode( mode ); 

} 

NSIMETHODIMP 

nsXPIDLPluginInstancePeer::GetTagInfo( nsIXPIDLPluginTagInfo2 ==" *aTagInfo ) 

nsIPluginT^n£o2 "'taglnfo; 
nsrestilt res = pluginlnstancePeer - > 

Querjinterface( NS_GET_IID(nsIPluginTagInfo2), (void **)8aagInfo ); 
if(]SIS_FAILED(ies)) { 

*aTagInfo =NULL; 

return res; 

} 

"^aTaglnfo = new nsXPIDLPluginTagInfo2( taglnfo ); 
return res; 

} 

NS_IMETHODIMP 

iisXPIDLPluginInstancePeen:GetValvie( PR[nt32 variable, char **_retval ) 
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nsPluginlnstancePeerVariable var = (nsPluginInstancePeerVariable)variable; 
return pluginlnstancePeer- >GetValue( var, (void *)'^_retval ); 

} 

NSJMEIHODIMP 

nsXPIDLPlugmInstancePeer::NewStream( const char ""type, 
const char "'target, 
nsIXPIDLOutputStream '^"^^retval ) 

{ 

nsIOutputStream *^*^oStream; 

nsresult nsRes = pluginlnstancePee-r- >NewStream( type, target, oStream); 
'^_retval = new nsXPIDLOutputStream( "oStream); 
return nsRes; 

} 

NSJMEIHODIMP 

mXPIDLPliigmInstancePeer::SetWindowSize(PRlJint32 width, PRUint32 height) 

return pluginlnstancePeer- >SetWindowSi2e( width, height ); 

} 

NSJMEIHODIMP 

nsXPIDLPluginInstancePeeK:ShowStatus( const char ''■message ) 
{ 

return pluginlnstancePeer- >ShowStatus( message ); 

} 



The C header file for the interface is as follows: 

# if ndef _nsXPIDLPluginInstancePeer_included_ 

# define __nsXPIDLPluginInstancePeer_included_ 

# include "nsIXPIDLPluginlnstancePeerh" 

# include "nsIPluginlnstancePeerh" 

class nsXPIDLPluginlnstancePeer : public nsIXPIDLPluginlnstancePeer 

{ 

public: 

NS_DEGLJSUPPORTS 

NS^DECL_NSIXPIDLPLUGIMNSTANCEPEER 
nsXPIDLPluginlnstancePeerQ ; 

nsXPIDLPluginInstancePeer( nsIPluginlnstancePeer "^pluginlnstancePeer); 
virtual ^sXPIDLPluginlnstancePeerO; 
nsIPluginlnstancePeer '^pluginlnstancePeer, 

}; 

# endif / / _nsXPIDLPluginInstancePeer_included_ 
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Interface: Plug- In Manag er 

Description: an interface designed to allow communication between plug-in and 
browser 



The scriptable IDL for this interface is nsIXPIDLPluginManager and is as follows: 



# include "nsISupports.idl" 

10 # include "nsIXPIDLPluginStreamListeneridl" 

# pragma prefix 

[scriptable, Uuid(fl7f6008-e31f-4410-b59b-0bd7df4e4f9b)] 
interface nsIXPIDLPluginManager : nsISupports 

1 5 void getURL( in nsISupports p%inlnstance, 

in string url, 
in string target, 

iS: in nsIXPIDLPluginStreamListener streamListener, 

p in string altHost, 

p 20 in string referrer, 

f IJ in boolean forceJSEnabled ); 

W void postURL( in nsISupports pliginlnstance, 

S3 in string url, 

S3 in unsigned long postDataLength, 

^ 25 [array, size_is (postDataLength)] in octet postData, 

f in unsigned long postHeadersLength, 

in string postHeaders, 
I in boolean isFile, 

in string target, 

" 30 in nsIXPIDLPluginStreamListener streamListener, 

in string altHost, 
in string referrer, 
in boolean forceJSEnabled ); 
void reloadPlugins( in boolean reloadPages ); 
3 5 string userAgentQ ; 

}; 



The C code file for the interface is: 



# include "nsIPluginManager.h" 

# include "nsXPIDLPluginManager.h" 

# include "nsXPIDLPluginManager2.h" 
include "nsXPIDLPluginStreamListener.h" 

45 NSJMPLJSUPPORTSl(nsXPIDLPluginManager, nsIXPIDLPluginManager) 

nsXPIDLPluginManager: :nsXPIDLPluginManager() 
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{ 

NSJMTJSUPPORTSO; 
} . 

nsXPIDIJlugmMan^er::nsXPIDLPlugiiiMan nsIPluginManager '*'plugmManager ) 

{ 

NSJMTJSUPPORTSO; 

this- >pli:^inManager = pluginManager, 

NS_ADDREF( pluginMan^er ); 

} ~ . 

nsXPIDLPluguiManager:: ^sXPIDLPluginManagerQ 

{ 

NS_RELEASE( pluginManager ); 

} 

NS_IMETHODIMP 

nsXPIDIJ?luginManager::GetIJRL( nsISuppoits *pliginlnstance, 

const char ''"url, 
const char '^target, 

nsIXPIDLPlt^StreamListener *streamList)ener, 
const char ''"altffost, 
const char ^referrer, 
PRBool forceJSEnabled) 

^ . . . 

nsIPluginStrcamListener ^sListener = new nsXPIDIJPluginStxeamListener( 
streamListener); 

return pluginManager- >GetURL( pliginlnstance, 

(char ''')url, 

(char '^)target, 

sListener, 

(char ''')altHost, 

(char *^)refemer, 

forceJSEnabled); 

} 

NSJMETHODIMP 

nsXPIDlJ^luginManager::PostXJKL( nsISupports "pliginlnstancej 
const char '^url, 
PRUmt32 postDataLength, 
PRUintS ''postData, 
PRlJmt32 postHeadersLength, 
const char "postHeaders, 
PRBool isFile, 
const char "'target, 

nsIXPIDLPluginStreamListener ^streamListener, 
const char " altHost, 
const char '^referrer, 
PRBool forceJSEnabled) 

{ 
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nsIPluginStreamListener '^'sListener = new nsXPIDLPluginStiieaniListener( 

streamListener); 
rctum pluginManager- >PostURL{ pKginlnstance, (char '^)iirl, 

postDataLength, 

(char "'jpostData, 

isFile, 

(char "')tai^et, 

sListener, 

(char '^)altHost, 

(char "')referrer, 

forceJSEnabled, 

postHeadersLength, 

postHeaders ); 

} 

NS_IMETHODIMP 

mXPIDIJPluginManager: JleloadPlugins( PRBool reloadPages ) 
{ 

return pluginManager- >ReloadPlugins( reloadPages ); 

} 

NSIMETHODIMP 

mXPIDLPluginManager::UserAgent( char ''■''"_retval ) 
{ 

return pli^uiManager- >UserAgent( (const char '''"')_retval ); 

} 



The C header file for the interface is as follows: 



# ifndef _nsXPIDLPluginManager_included_ 

# define _nsXPIDLPluginManager_included_ 

# include "nsIXPIDLPluginManagenh" 
include "nsIPluginManager.h" 

class nsXPIDLPluginManager : public nsIXPIDLPluginManager 

{ 

public: 

NS_DECL_ISUPPORTS 
NS_DECL_NSIXPIDLPLUGINMANAGER 
nsXPIDLPluginManagerO ; 

nsXPIDLPluginManager( nsIPluginManager "pluginManager); 
virtual ^sXPIDLPluginManagerQ; 
nsIPluginManager ''"pluginManager; 

# endif / / _nsXPIDLPluginManager_included_ 
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Interface: Plug- in Manager 2 

Description: an interface designed to be a support interface to plug-in manager 
interface 

The scriptable IDL fortius interface is nsIXPIDLPlugitiManager2 and is as follows: 

# include "nsIXPIDLPluginManageridr' 

# pragma prefix 

[scriptable, uuid(33731e21-dfe3-4abc-b921>8cd6ccfb0e32)] 
interface nsIXPIDLPluginManager2 : nsIXPIDIPlugiaManager 

void beginWaitCursorO; 

void endWaitCursorQ; 

string findProx^orURL( in string url ); 

boolean supportsURLProtocol( in string protocol ); 

}; 



The C code file for the interface is: 



# include "nsXPIDLPluginManager2.h" 

NS_IMPL_ISUPPORTSl(nsXPIDLPluginManager2, nsIXPIDLPluginManager2) 

nsXPIDLPluginManager2::nsXPIDLPluginManager20 

{ 

NS_INIT_ISUPPORTS0; 

} 

mXPIDIPlugmManager2::nsXP]DIJ^luginManage 
'^pluginManager ) 

{ 

NS_IMT_ISUPPORTS 0; 

this- >pluginManager = pluginManagei^ 

]SIS_ADDREF( pluginManager); 

} 

nsXPIDLPluginManager2:: -nsXPIDLPluginManager20 
{ 

NS_RELEASE( pluginManager ); 

} 

NS_IMETHODIMP 

nsXPIDLPli^inManager2::BeginWaitCiirsorO 

return pluginls/knager- ^BeginWaitCursorQ; 

} 

NSJMETHODIMP 
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nsXPIDLPluginManager2::EndWaitGursorO 
{ 

return pluguiManager- >EndWaitGursorQ; 

} 

NS_IMETHODIMP 

mXPIDIJPli^iiiMinager2: J'indProxjf'orURL( const char *iirl, char **_retval ) 
{ 

retiim plxiginManager- ::i^indProxyForURL( url, _retval ); 

} 

NS_IMETHODIMP 

iisXPIDLPlugiriN/fenager2::SupportsURLProtocol( const char *protocol, 
PRBool*_retval) 

{ 

return pluginManager- >SupportsURLProtocol( protocol, _retval) 

} 

// from nsXPIDLPluginManager 
NSJMETHODIMP 

nsXPIDIJliiginManager2::GetURL( nsISupports '^pliginlnstance, 
const char "url, 
const char "'tai^et, 

nsIXPIDLPluginStreamListener '^streamlistener, 
const char *altHost, 
const char "'referrer, 
PRBool forceJSEnabled ) 

{ 

return mXPIDU^liiginManager::GetURL( pliginlnstance, 
url, 

taiget, 

streamListener, 

altHost, 

referrer, 

forceJSEnabled); 

} 

NSJMETHODIMP 

nsXPIDLPluginManager2::PostURL( nsISupports *^pliginlnstance, 
const char "^"url, 
PRUint32 postDataLength, 
PRUintS ^^postData, 
PRUmt32 postHfeadersLength, 
const char '^postHeaders, 
PRBool isFile, 
const char "^target, 

nsIXPIDLPluginStreamListener ^^streamListener, 
const char "altHost, 
const char '^referrer, 
PRBool forceJSEnabled ) 
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retxun nsXPIDLPlugmManager::PostlJRL( pliginlnstance, 
url, 

postDataLength, 
postData, 

postHeadersLength, 

postHeaders, 

isFile, 

target, 

stneamListener, 

altHost, 

referrer, 

forceJSEnabled); 

} 

NSIMETHODIMP 

nsXPIDIJ*li^inManager2::ReloadPlvigins( PRBool reloadPages ) 
{ 

retxim nsXPIDLPlugmManager::ReloadPlugms( reloadPages ); 

} 

NSIMETHODIMP 

nsXPIDLPlugiiiManager2::UserAgent( char ""*_retval ) 
{ 

return nsXPIDLPluginManager::UserAgent( _retval ); 

} 



The C header file for the interface is as follows: 



# ifndef _nsXPIDLPluginManager2_included_ 

# define _nsXPIDLPluginManager2_included_ 

# include "nsIXPIDLPluginManager2.h" 

# include "nsIPluginManager2.h" 

# include "nsXPIDLPluginManagenh" 

class nsXPIDLPluginManager2 : public nsXPIDLPluginManager, public 
nsIXPIDLPluginManager2 

{ 

public: 

NS_DECL_ISUPPORTS 
NS_DECL_NSIXPIDLPLUGINMANAGER2 
NS_DECL_NSIXPIDLPLUGI^MANAGER 
nsXPIDLPli^inManager20 ; 

nsXPIDLPluginManager2( nsIPluginManager2 *pluguiMian£^er); 
virtual ~nsXPIDLPluginManager20; 
nsIPlugiiiManager2 *pluginManager, 

}; 
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# endif / / _nsXPIDLPlugmManager2_included 



Interface: Plug- In Stream Infomiation 

5 

Description: an interface designed to enable the plug- in to access information on 
incoming data streams 



10 The scriptable IDL for this interface is nsIXPIDLPluginStreamlnfo and is as follows: 

# include "nsISupports.idl" 

# pragma prefix 

[scriptable, uuid(lbdlel09-7b4c-4820-a80d-2e04b709e74a)] 
15 interface nsIXPIDLPluginStreamlnfo : nsISupports 

{ 

readonly attribute string contentType; 
.4 readonly attribute unsigned long lastModified; 

: -i readonly attribute vinsigned long length; 

11 20 readonly attribute wstrir^ URL; 

y boolean isSeekableQ; 

y void requestRead( in unsigned long count, 

f [array size_is (count)] in long offsets, 

[array, size_is(count)] in unsigned long lengths ); 

^ 25 }; 



The C code file for the interface is: 



30 

u # include "nsXPIDLPluginStreamlnfo.h" 

NSIMPLISUPPORTS 1 (nsXPIDLPluginStreamlnfo, nsIXPIDLPluginStreamlnfo) 

nsXPIDLPluginStreamInfo::nsXPIDLPluginStreamInfoO 

{ 

35 NSJMTJSUPPORTSO; 
} 

nsXPIDIJ^luginStreaniInfo::nsXPIDLPluginStrean[i[nfo(nsIPlugin^ 
"pluginStreanciInfo ) 

{ 

40 NSJMTJSUPPORTSO; 

this- >plugiQStreamInfo = pluginStreamlnfo; 
NS_ADDREF( pluginStreamlnfo ); 

} 

nsXPIDLPluginStreamlnfo:: -nsXPIDLPluginStreamlnfoO 
45 { 

NS_RELEASE( pluginStreamlnfo ); 
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} 

NS_IMETHODIMP 

nsXPIDLPluginStreain[nfo::GetContentType( char * ^aContentType ) 
{ 

return pluginStreamlnfo- >GetContentType( (nsMIMEType "')aContentType ); 

} 

NS_IME'IHODIMP 

mXPIDIPlxjgmStieairiInfo::GetLaslModified( PRUmt32 ^aLastModified) 
return pluginStreamlnfo >GetLastModified( aLastModified ); 

} 

NS_IMETHODIMP 

nsXPIDLPlugmStreamInfo::GetLength( PRUint32 *aLength ) 
{ 

return plugmStreamlnfo- XjetLer^;th( aLength ); 

} 

NS_IMEIHODIMP 

nsXPIDLPluginStreamInfo::GetURL( PRUnichar * *aURL ) 
{ • 

return pluginStreamlnfo- XjetURL( (const char '*'*'")aURL ); 

} 

NS_IMETHODIMP 

nsXPIDLPluginStieamInfo::IsSeekable( PRBool *_ietval) 
{ 

return pluginStreamlnfo- >JsSeekable( _retval ); 

} 

NSJMETHODIMP 

nsXPIDLPli:^mStreamInfo::RequestRead( PRUmt32 count, 
PRInt32 ^offsets, 
PRUmt32 ^lengths ) 

{ 

nsByteRange ''"rangeList, "last; 

/ / rekolbasing data to nsByteRange structure 

for( int i=0; i <:ount; i+ + ) { 

nsByteRange '^newRange == newnsByteRangeQ; 

newRange- >3ffset = offsets[i]; 

newRange- >iengtli = lengths[i]; 

newRange- >iext = NULL; 

if( i « = 0 ) rangeList « last = newRange; 
else { 

last- >next newRange; 
last = last- >iext; 

} 

} 

/ / make a call 

return pluginStreamlnfo- >RequestRead( rangeList ); 
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} 



The C header file for the interface is as follows: 



# ifndef _nsXPIDLPluginStreamInf o_included_ 

# define _nsXPIDLPluginStreaniInfo_included__ 

# include "nsIXPIDLPluginStreamInfo.h" 

# include "nsIPluginStreamlnfo-h" 

ckss nsXPIDLPluginStreamlnfo : public nsIXPIDLPluginStreamlnfo 

{ 

public: 

NS_DECL_ISUPPORTS 

NSDECLNSIXPIDLPLUGINSTREAMINFO 

nsXPIDLPluginStreamlnfoQ; 

nsXPIDLPluginStreamlnfo ( nsIPluginStreamlnfo '^pluginStreamlnfo); 
virtual --nsXPEDLPluginStreamlnfoO; 
nsIPluginStreamlnfo *pluginStreamInfo; 

# endif / / _nsXPIDLPluginStreani[nf o_included_ 



Interface: Plug-In Stream Listener 

Description: an interface designed to enable the plug- in to handle incoming data 
streams 



The scriptable IDL for this interface is nsIXPIDLPluginStreamListener and is as 

follows: 



# include "nsISupports.idl" 

# include "nsIXPIDLPluginStreamlnfo.idl" 

# include "nsIXPIDLInputStream.idl" 

# pragma prefix 

[scriptable, uuid(c26d873a-9a7d-48D2^8a52-e6d67eafd9c9)] 
interface nsIXPIDLPluginStreamListener : nsISupports 

{ 

const unsigned long STREAM_TYPE_NORMAL = 1; 

const unsigned long STREAM_TYPE_SEEK = 2; 

const unsigned long STREAM:_TYPE_AS_FILE =3; 

const unsigned long STREAM_TYPE_AS_FILE_ONLY = 4; 

readonly attribute uns^ned long streamType; 

void onDataAvailable( in nsIXPIDLPluginStreanilnfo streamlnfo. 
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in nsIXPIDLInputStream input, 

in ims^ned long length ); 
void onFileAvailable( in nsIXPIDLPluginStreamlnfo streamlnfo, 

in wstring fileName ); 
void onStartBinding( in nsIXPIDLPluginStreamlnfo streamlnfo ); 
void onStopBinding( in nsIXPIDLPluginStreamlnfo streamlnfo, 

in loi^ status ); 

}; 



The C code file for the interface is: 



# include "nsIPluginStreamListener.h" 

# include "nsXPIDLPluginStreamListener.h" 

NS_IMPL_ISUPPORTS 1 (nsXPIDLPluginStreamListener, nsIPluginStreamlistener) 
nsXPIDLPluginStreamListener::nsXPIDLPluginStreamListenerO 

{ 

NSJNITJSUPPORTSO; 
} . . 

nsXPIDLPluginStreamListener::nsXPIDLPluginStreamListener( 
nsIXPIDLPluginStreamListener pluginStreamListener ) 

{ 

NSJNITJSUPPORTSO; 

this- >pluginStxeaniListener = pluginStreamListener, 
NS_ADDREF( pluginStreamlistener ); 

nsXPIDLPliiginStreamI^tener::'-iisXPIDIJ?lx:^inStreamListener() 

{ 

NS_RELEASE( pluginStreamListener); 

} 

NSJMETHODIMP 

nsXPIDlJ*liigmStreaniIistener::GetStteamType( nsPluginStreamType ^result ) 
{ 

retum pluginStreamListener- >GetStreamType( (PRUint32 "')result ); 

} 

NSJMETHODIMP 

nsXPnDIPlugmStreainListener:OnDataAvailabk( nsIPluginStreamlnfo *streamInfo, 

nsIInputStneam *input, 
PRUint32 length) 

{ 

nsIXPIDLPluginStreamlnfo *^slnf o = new nsXPIDLPluginStreamlnfo 

(streamlnfo); 

nsIXPIDLInputStream "^Stream = new nsXPIDLInputStream( input ); 
retum pluginStreamListener- >OnDataAvailable( sinfo, iStream, length ); 

} 
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NSJMETHODIMP 

nsXPlDIJPlugmStiTeamListeneKiOnFileAvan^ nsIPliiginStiieainltifo ^^streamlnfo, 
const char *^fileNanie ) 

5 nsIXPIDLPluginStreamInf o '*sIn£o = new nsXPIDLPluginStreamlnfo 

(stxeamlnfo); 

return pluginStreamlistener- >OnF]ileAvailable( sinfo, (PRUnichar *^)fileNan:ie ); 

} 

NS_IMETHODIMP 

1 0 nsXPIDLPliiginStteamlJstenen:OnStarlJBindmg( nsIPluginStreamlnf o *strcamlnf o ) 

{ . ^ 

nsIXPIDLPluginStreamlnfo "^slnfo =newnsXPIDLPluginStrean£nfo 

(streamlnfo); 
return pluginStreamListener- >QnStartBinding( sInfo ); 

15 } 

NSJMETHODIMP 

mXPIDlJ?luginStreaniListenen:OnStopBinding( nsIPluginStreamlnfo '^streamlnfo, 
nsresult status ) 

{ 

20 nsIXPIDLPluginStreamlnfo '^slnfo = new nsXPIDLPluginStreamlnfo 

( streamlnfo ); 

return pluginStreamListener- >OnStopBinding( sInfo, (PRInt32)status ); 

} 
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The C header ffle for the interface is as follows: 



# ifndef _nsXPIDLPluginStreamListener_included_ 

# define _nsXPIDLPluginStreaniListener_included_ 
30 # include "nsIPluginStreamListenenh" 

# include "nsIXPIDLPluginStreamListener.h" 

# include "nsIPluginStreamInfo.h" 

# include "nsXPIDLPluginStreamInfo.h" 

# include "nsIInputStream.h" 

35 # include "nsXPIDLInputStream.h" 

class nsXPIDLPluginStreamListener : public nsIPluginStreamListener 

{ 

public: 

NS^DECLISUPPORTS 
40 // NS_DEGL^NSIXPIDLPLUGINSTREAMLISTENER 

nsXPIDLPluginStreamListenerQ ; 

nsXPIDLPluginStreamListener( nsIXPIDLPluginStreamListener 

pluginStreamListener ); 
virtual NsXPIDLPluginStreamListenerQ; 
45 nsIXPIDLPluginStreamListener pluginStreamListener, 

// from nsIPluginStreanaListener 
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NSJMETHODIMP GetStreamType( nsPluginStreamType ''Tesult); 
NS_IMETHODIMP OnDataAvailable(nsIPli^mStreamInfo *stieamInfo, 

nsIInputStream *input, 

PRUnt32 length); 
NSJMETHODIMP OnFileAvailable( nsIPluginStrcamlnfo *strcamInfo, 

const char *fileName ); 
NSJMETHODIMP OnStartBindmg( nsIPluginStrcamlnfo *streamInfo ); 
NS_IMETHODIMP OnStopBmcling( nsIPluginStrcamlnfo *strcamInfo, 
nsresult status ); 

# endif / / _nsXPIDIPluginStreamljstener_included_ 



Interface: Plug-In Tag Information 

Description: an interface designed to enable the plug- in to access HTML tag 
information from the browser 



The scriptable IDL for this interface is nsIXPIDLPluginTaglnfo and is as follows: 

# include "nsISupports.idl" 

# pragma prefix 

[scriptable, Uuid(b6506c8a-aaa7-4dd7-a3aa-cb3632f40a48)] 
interface nsIXPIDLPluginTaglnfo : nsISupports 

string get Attribute ( in string name ); 

void getAttributes( out unsigned long count, 

[array, si2e_is (count)] out string names, 

[array, size_is (count)] out string values ); 

}; 

The C code file for the interface is: 



# include "nsXPIDLPluginTagInfo.h" 

NS_IMPLJSUPPORTSl(nsXPIDLPluginTagInfo, nsIXPIDLPluginTaglnfo) 

nsXPIDLPluginTagInfo:aisXPIDLPluginTagInfoO 

{ 

NS_IMTJSUPPORTS0; 

} 

nsXPIDLPluginTagInfo::nsXPIDLPluginTagInfo( nsIPluginTaglnfo '^taglnfo ) 
{ 

NS_IMTISUPPORTS0; 
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this- Xaglnfo = taglnfo; 
NS_ADDREF(tagInfo); 

} 

nsXPIDLPluginTaglnfo:: -iisXPIDLPluginT^InfoQ 
5 { 

NS_RELEASE( taglnfo); 

} 

NS_IME'THODIMP 

nsXPIDLPluginTagInfo::GetAttribute( const char '''name, char "'*_retval) 
10 { 

return NSERRORNOTIMPLEMENTED; 

} 

NSJMETHODIMP 

nsXPIDLPli^TagInfo::GetAttributes( PRUm62 *count, 
15 char '^'•■'''names, 

char "''^^valiies ) 

{ 

I* return NS_ERROR_NOT_IMPLEMENTED; 

b } 

C3 20 

i«J The C header file for the interface is as follows: 



25 #ifndef_nsXHDLPhiginTagInfo_incbded_ 
: # define _nsXPIDLPluginTagInfo_included_ 

# include "nsIXPIDLPluginTaglnfch" 

# include "nsIPluginTaglnfo.h" 

IZ class nsXPIDLPluginTaglnfo : public nsIXPIDLPlv^inTaglnfo 

S 30 { 

hA public: 

NS_DECL_ISUPPORTS 

NS_DECL_NSIXPIDLPLUGINTAGINFO 

nsXPIDLPluginTaglnfoO; 
35 nsXPIDLPluginTagInfo( nsIPluginTaglnfo *tagInfo ); 

virtual -^isXPIDLPluginTaglnfoQ; 

nsIPluginTaglnfo ^taglnfo; 

}; 

# endif // _nsXPIDLPlugmTagInfo_included_ 

40 

Interface: Plug- In Tag Inforaiation 2 

Description: an interface des^ned to support plug- in tag information interface 
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The scriptable IDL for this interface is nsIXPIDLPli^inTagInfo2 and is as follows: 



# include "nsIXPIDLPluginTaglnfoidl" 

# pragma prefix 

[scriptable, uuid(144542ea-52a5-466f-ac65-a34ecbd9966e)] 
interface nsIXPIDLPluginTagInf o2 : nsIXPIDLPluginTaglnfo 

readonly attribute string alignment; 

string getParameter( in strii^ name ); 

void getParameters( out unsigned long count, 

[army, size_is (count)] out string names, 

[array, si2e_is (count)] out string values ); 

readonly attribute unsigned long borderHorizSpace; 

readonly attribute unsigned long borderVertSpace; 

readonly attribute string documentBase; 

readonly attribute string documentEncoding; 

readonly attribute unsigned long height; 

readonly attribute unsigned long width; 

readonly attribute string tagText; 

readonly attribute string tagType; 

readonly attribute unsigned long uniquelD; 

}; 



The C code file for the interface is: 



# include •'nsXPIDLPluginTagInfo2.h" 

NS_IMPL_ISUPPORTS 1 (nsXPIDLPluginTagInfo2, nsIXPIDLPluginTagInfo2) 
nsXPIDLPli^inTagInfo2::nsXPIDLPluginTagInfo2() 

NS_INIT_ISUPPORTS0; 

} 

nsXPIDLPluginTagInfo2::nsXPIDLPluginTagInfo2( nsIPluginTagInfo2 *tagInfo ) 

NS_IMT_ISUPPORTS0; 
this- >tagInfo = taglnfo; 
NS_ADDREF(tagInfo); 

} 

nsXPIDLPluginTagInfo2::-^isXPIDLPlv^inTagInfo20 
{ 

NS_RELEASE( taglnfo); 

} 

NS IMETHODIMP 
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nsXPIDLPluginTagInfo2::GetAlignment( char '''aAlignment ) 

{ 

return taglnfo- >GetAlignment( (const char '^'^)aAligiiment ); 

} 

NSJMETHODIMP 

nsXPIDLPlugmTagInfo2::GetParameter( const char *name, char **_tei:val ) 
{ 

return taglnfo- >GetParameter( name, (const char '^■''^)_retval ); 

} 

NS_IME'IHODIMP 

nsXPIDLPlugmTagInfo2::GetParameters( PRUmt32 *count, 
char ^'-''''names, 
char values ) 

{ 

return taglnfo- >GetParameters( (PRUintl6)'^count, 

(const char"const'^)'^names, 
(const chaf^const"^) "values ); 

} 

NSJMETHODIMP 

nsXPIDLPluginT^nfo2::GetBotderHorizSpace( PRUmt32 ^aBonkrHorizSpace ) 
{ 

return taglnfo- >GetBorderHori2Space( aBorderHorizSpace ); 

} 

NS_IMETHODIMP 

nsXPIDLPluginTagInfo2::GetBorderVertSpace( PRIJmt32 '^aBorderVertSpace ) 
{ 

return t^Info- XjetBorderVertSpace( aBorderVertSpace ); 

} 

NSJMETHODIMP 

nsXPIDLPliiginTagInfo2::GetDocumentBase( char * *aDociiinentBase ) 
{ 

return taglnfo- >GetDocunientBase( (const char ''""")aDocumentfiase ); 

} 

NS_IMETHODIMP 

nsXPIDLPliiginTagInfo2::GetDoaimentEncodmg( char * *aDoctjmentEncoding ) 
{ 

return taglnfo- XjetDocumentEncoding( (const char'^"')aDocumentEncoding ); 

} 

NSJMETHODIMP 

nsXPIDLPlugmTagInfo2::GetHeight( PRUmt32 *aHeight ) 
{ 

return taglnfo- XjetHeight( aHeight ); 

} 

NSJMETHODIMP 

nsXPIDLPlugmTagInfo2::GetWidth( PRUmt32 Widdi) 
{ 
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return taglnfo- >GetWidth( aWidth ); 

} 

NSJMETHODIMP 

nsXPIDLPlugmTagInfo2::GetTagText( char *aTagText) 
5 { 

return taglnfo- >GetTagText( (const char *^'^)aTagText); 

} 

NS_IMETHODIMP 

nsXPIDLPl;iginTagInfo2::GetTagType( char '''aTagType ) 

return taglnfo- >GetTagType( (nsPluginTagType *^)aTagType ); 

} 

NS_IMETHODIMP 

nsXPIDLPluginTagInfo2::GetUniqueID( PRUmt32 *aUmqueID ) 
return t^Info- >GetUniqueID( aUniquelD ); 

I * I 

// from Taglnfo 
NSJMETHODIMP 

bi 20 nsXPIDLPluginTagInfo2::GetAttribute( const char '^"name, char ''"'''_retval ) 

p { 

:2 return nsXPIDLPlugmTagInfo::GetAttribute( name, _retval ); 

p. } 

;:" NSJMETHODIMP 

25 nsXPIDLPlugmTagInfo2::GetAttributes(PRUin62*coimt, 

char ***naines, 
char ***valiies ) 

rii { 

O return nisXPIDLPluginTagInfo::GetAttributes( count, names, values ); 

I* 30 } 
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The C header file for the interface is as follows: 



# ifndef _nsXPIDLPluginTagInfo2_inclvicled_ 

# define _nsXPIDLPluginTagInfo2_included_ 

# include "nsIXPIDLPluginTagInfo2.h" 
40 # include "nsIPluginTagInfo2.h" 

# include "nsXPIDLPluginTaglnfch" 

class nsXPIDLPluginTagInf o2 : public nsXPIDLPli^inTaglnf o, public 
nsIXPIDLPluginTagInfo2 

{ 

45 public: 

NS DECL ISUPPORTS 



LA 55722v3 



41 



NS_DECL_NSIXPIDLPLUGINTAGINF02 
NS_DECL NSIXPIDLPLUGINTAGINFO 
nsXPIDLPluginTagInfo20; 

nsXPIDLPluginTagInfo2( nsIPluginTagInfo2 *tagInfo ); 
virtual ~nsXPIDLPluginTagInfo20; 
nsIPluginTagInfo2 ""taglnfo; 



# endif // _nsXPIDLPluginTagInf o2_included 
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Embodiment of Computer Execution Environment (Hardware) 

An embodiment of the invention can be implemented as computer software in the form 
of computer readable program code executed in a general purpose computing environment such 
5 as environment 700 illustrated in Figxxre 7, or in the form of bytecode class files executable 
within a Java™ run time environment running in such an environment, or in the form of 
bytecodes running on a processor (or devices enabled to process bytecodes) existing in a 
distributed environment (e.g., one or more processors on a network). A keyboard 710 and 
mouse 711 are coupled to a system bus 718, The keyboard and mouse are for introducing user 
h 1 0 input to the computer system and communicating that user input to central processing unit 
f y (CPU) 713. Other suitable input devices may be used in addition to, or in place of, the moi:ise 

I si! 

C3 711 and keyboard 710. I/O (input/output) unit 719 coupled to bi-directional system bus 718 

CO represents such 1/ O elements as a printer, A/V (audio/ video) 1/ O, etc. 

U; 

fU 

15 Computer 701 may include a communication interface 720 coupled to bus 718. 

Communication interface 720 provides a two-way data communication coupling via a network 
link 721 to a local network 722. For example, if communication interface 720 is an integrated 
services d^ital network (ISDN) card or a modem, communication interface 720 provides a data 
communication connection to the corresponding type of telephone line, which comprises part 

20 of network link 721. If communication interface 720 is a local area network (LAN) card, 

communication interface 720 provides a data communication connection via network link 721 to 
a compatible LAN. Wireless links are also possible. In any such implementation. 
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communication interface 720 sends and receives electrical, electromagnetic or optical signals 
which cany digital data streams representing various types of information. 

Network link 721 typically provides data communication through one or more networks 
to other data devices. For example, network link 721 may provide a connection through local 
network 722 to local server computer 723 or to data equipment operated by ISP 724. ISP 724 in 
turn provides data communication services through the world wide packet data commumcation 
network now commonly referred to as the "Internet" 725. Local network 722 and Internet 725 
both use electrical, electromagnetic or optical signals which carry digital data streams. The 
signals through the various networks and the signals on network link 721 and through 
communication interface 720, which cany the digital data to and from computer 700, are 
exemplary forms of carrier waves transporting the information. 

Processor 713 may reside wholly on client computer 701 or wholly on server 726 or 
processor 713 may have its computational power distributed between computer 701 and server 
726. Server 726 symbolically is represented in Figure 7 as one unit, but server 726 can also be 
distributed between multiple "tiers". In one embodiment, server 726 comprises a middle and 
back tier where application logic executes in the middle tier and persistent data is obtained in the 
back tier. In the case where processor 713 resides wholly on server 726, the results of the 
computations performed by processor 713 are transmitted to computer 701 via Intemet 725, 
Internet Service Provider (ISP) 724, local network 722 and communication interface 720. In this 
way, computer 701 is able to display the results of the computation to a tiser in the form of 
output. 
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Computer 701 includes a video memory 714, main memory 715 and mass storage 712, 
all coupled to bi-directional system bus 718 along with keyboard 710, mouse 711 and processor 
713. As with processor 713, in various computii^ environments, main memory 715 and mass 
5 storage 712, can reside wholly on server 726 or computer 701, or they may be distributed 
between the two. Examples of systems where processor 713, main memory 715, and mass 
storage 712 are distributed between computer 701 and server 726 include the thin-client 
computing architecture developed by Sun Microsystems, Inc., the palm pilot computii^ device 
and other personal digital assistants, Internet ready cellular phones and other Intemet computing 

pi 10 devices, and in platform mdependent computing environments, such as those which utilize the 

■ n Java™ technologies also devebped by Sun Microsystems, Inc. 



The mass storage 712 may include both fixed and removable media, such as magnetic, 
optical or magnetic optical storage systems or any other available mass storage technology. Bus 
15 718 may contain, for example, thirty two address lines for addressing video memory 714 or main 
memory 715. The system bus 718 also includes, for example, a 32- bit data bus for transferrii^ 
data between and among the components, such as processor 713, main memory 715, video 
memory 714 and mass stor^e 712. Alternatively, multiplex data/address lines maybe used 
instead of separate data and address lines. 
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In one embodiment of the invention, the processor 713 is a SPARC microprocessor 
from Sun Microsystems, Inc., a microprocessor manufactured by Motorola, such as the 680X0 
processor, or a microprocessor manufactured by Intel, such as the 80X86 or Pentium processor. 
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However, any other suitable microprocessor or microcomputer may be utilized. Main memory 
715 is comprised of dynamic random access memory (DRAM). Video memory 714 is a dual- 
ported video random access memory. One port of the video memory 714 is coupled to video 
amplifier 716. The video amplifier 716 is used to drive the cathode ray tube (CRT) raster 
monitor 717. Video amplifier 716 is well known in the art and may be implemented by any 
suitable apparatus. This circuitry converts pixel data stored in video memory 714 to a raster 
signal suitable for use by monitor 717. Monitor 717 is a type of monitor suitable for displaying 
graphic images. 

Computer 701 can send messages and receive data, includir^ program code, through the 
network(s), network link 721, and communication interface 720. In the Internet example, 
remote server computer 726 might transmit a requested code for an application program 
through Internet 725, ISP 724, local network 722 and communication interface 720. The 
received code may be executed by processor 713 as it is received, and/ or stored in mass storage 
712, or other non- volatile storage for later execution. In this marmer, computer 700 may obtain 
application code in the form of a carrier wave. Altematively, remote server computer 726 may 
execute applications using processor 713, and utilize mass storage 712, and/ or video memory 
715. The results of the execution at server 726 are then transmitted through Internet 725, ISP 
724, local network 722 and communication interface 720. In this example, computer 701 
performs only input and output functions. 

In one embodiment of the present invention, the scriptable plug-in 752 can reside on 
server 726, In one embodiment of the present invention, scriptable plug- in 752 is developed 
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earlier on the server with scriptable plug-in API 750. Non-scriptable browser plug-in API 760, 
as part of a browser, is on computer 701. The browser can download scriptable plug-in 752 
from server 726 when it encotinters a plug-in reference on an HTML page. Scriptable plug-in 
API 750 also resides with the browser plug-in API 760 on computer 701. Scriptable plug-in API 
750 enables the execution of scriptable plug- in 752 on computer 701. 

Application code may be embodied in any form of computer program product, A 
computer program product comprises a medium configured to store or transport computer 
readable code, or in which computer readable code may be embedded. Some examples of 
computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, 
computer hard drives, servers on a network, and carrier waves. 

The computer systems described above are for pxu:poses of example only. An 
embodiment of the invention may be implemented in any type of computer system or 
programming or processing environment. 

Thus, an implementation of a scriptable plug-in API is described in conjunction with 
one or more specific embodiments. The invention is defined by the claims and their full 
scope of equivalents. 
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